Ingeniería De Requerimientos Ingeniería De Software (página 2)

3. Técnicas y
herramientas
utilizadas en la ingeniería de requerimientos

Técnicas utilizadas en la actividades de IR

Existen varias técnicas para la IR, sin embargo, en
este documento se van a estudiar sólo algunas de ellas.
Cada técnica puede aplicarse en una o más
actividades de la IR; en la práctica, la técnica
más apropiada para cada actividad dependerá del
proyecto que
esté desarrollándose.

Este análisis de técnica vs. actividad
será discutido en el capítulo IV. Por el momento
sólo mencionaremos en qué consiste cada
técnica.

Entrevistas y Cuestionarios

Las entrevistas y
cuestionarios se emplean para reunir información proveniente de personas o de
grupos.
Durante la entrevista,
el analista conversa con el encuestado; el cuestionario
consiste en una serie de preguntas relacionadas con varios
aspectos de un sistema.

Por lo común, los encuestados son usuarios de los
sistemas
existentes o usuarios en potencia del
sistema
propuesto. En algunos casos, son gerentes o empleados que
proporcionan datos para el
sistema propuesto o que serán afectados por
él.

Las preguntas que deben realizarse en esta técnica,
deben ser preguntas de alto nivel y abstractas que pueden
realizarse al inicio del proyecto para
obtener información sobre aspectos globales del
problema del usuario y soluciones
potenciales.

Con frecuencia, se utilizan preguntas abiertas para
descubrir sentimientos, opiniones y experiencias generales, o
para explorar un proceso o
problema. Este tipo de preguntas son siempre apropiadas,
además que ayudan a entender la perspectiva del afectado y
no están influenciadas por el
conocimiento de la solución.

Las preguntas pueden ser enfocadas a un elemento del
sistema, tales como usuarios, procesos, etc.
El siguiente ejemplo muestra algunos
tipos de preguntas abiertas.

Del Usuario

• ¿Quién es el cliente?
• ¿Quién es el usuario?
• ¿Son sus necesidades diferentes?
• ¿Cuáles son sus habilidades, capacidades,
  ambiente?

Del Proceso

• ¿Cuál es la razón por la que se
  quiere resolver este problema?
• ¿Cuál es el valor de una
  solución exitosa?
• ¿Cómo usted resuelve el problema
  actualmente?
• ¿Qué retrasos ocurren o pueden
  ocurrir?

Del Producto

• ¿Qué problemas
  podría causar este producto en
  el negocio?
• ¿En qué ambiente se
  usará el producto?
• ¿Cuáles son sus expectativas para los
  conceptos fácil de usar, confiable,
  rendimiento?
• ¿Qué obstáculos afectan la eficiencia del
  sistema?

El éxito
de esta técnica combinada, depende de la habilidad del
entrevistador y de su preparación para la misma. Los
analistas necesitan ser sensibles las dificultades que algunos
entrevistados crean durante la entrevista y
saber cómo tratar con problemas
potenciales. Asimismo, necesitan considerar no sólo la
información que adquieren a través del cuestionario y
la entrevista,
sino también, su significancia.

Lluvia de Ideas (Brainstorm)
Este método
comenzó en el ámbito de las empresas,
aplicándose a temas tan variados como la productividad, la
necesidad de encontrar nuevas ideas y soluciones
para los productos del
mercado,
encontrar nuevos métodos
que desarrollen el pensamiento
creativo a todos los niveles, etc. Pero pronto se extendió
a otros ámbitos, incluyendo el mundo de desarrollo de
sistemas;
básicamente se busca que los involucrados en un proyecto
desarrollen su creatividad,
promoviendo la introducción de los principios
creáticos.

A esta técnica se le conoce también como
torbellino de ideas, tormenta de ideas, desencadenamiento de
ideas, movilización verbal, bombardeo de ideas, sacudidas
de cerebros, promoción de ideas, tormenta cerebral,
avalancha de ideas, tempestad en el cerebro y
tempestad de ideas, entre otras.

Principios de la lluvia de ideas

• Aplazar el juicio y no realizar críticas, hasta
  que no agoten las ideas, ya que actuaría como un
  inhibidor. Se ha de crear una atmósfera de trabajo en la que nadie se
  sienta amenazado.
• Cuantas más ideas se sugieren, mejores resultados
  se conseguirán: "la cantidad produce la calidad". Las
  mejores ideas aparecen tarde en el periodo de producción de ideas, será
  más fácil que encontremos las soluciones y
  tendremos más variedad sobre la que elegir.
• La producción de ideas en grupos puede
  ser más efectiva que la individual.
• Tampoco debemos olvidar que durante las sesiones, las
  ideas de una persona,
  serán asociadas de manera distinta por cada miembro, y
  hará que aparezcan otras por contacto.

El equipo en una lluvia de ideas debe estar formado
por:

El Director: es la figura principal y el encargado de
dirigir la sesión. Debe ser un experto en pensamiento
creador. Su función es
formular claramente el problema y que todos se familiaricen con
él. Cuando lo haga, debe estimular ideas y hacer que se
rompa el hielo en el grupo. Es el
encargado de que se cumplan las normas, no
permitiendo las críticas. Debe permanecer callado e
intervenir cuando se corte la afluencia de ideas, por lo que le
será útil llevar ya un listado de ideas. Debe hacer
que todos participen y den ideas. Además, es la persona que da
concede la palabra y da por finalizada la sesión.
Posteriormente, clasificará las ideas de la lista que le
proporciona el secretario. 

El secretario: registra por escrito las ideas
según van surgiendo. Las enumera, las reproduce fielmente,
las redacta y se asegura que todos están de acuerdo con lo
escrito. Por último realizará una lista de
ideas. 

Los participantes: pueden ser habituales o invitados;
cualquier involucrado en el proyecto entra en esta
categoría. Su función es producir ideas. Conviene
que entre ellos no halla diferencias jerárquicas.

Las personas que componen el grupo deben
estar motivadas para solucionar el problema, y con un ambiente
que propicie la participación de todos. Todos pueden
sentirse confiados y con la sensación de que pueden hablar
sin que se produzcan críticas. Todas las ideas en
principio deben tener el mismo valor, pues
cualquiera de ellas puede ser la clave para la solución.
Es necesario prestar mucha atención a las frases que pueden coartar la
producción de ideas. Además durante la
celebración no deben asistir espectadores.

Debemos evitar todos los bloqueos que paralizan la
ideación: como son nuestros hábitos o ideas
preconcebidas, el desánimo o falta de confianza en si
mismo, el temor y la timidez.

Las fases de aplicación en el Brainstorm son:

Descubrir hechos

Al menos con un día de antelación, el director
comunica por escrito a los miembros del grupo sobre los temas a
tratar. El director explica los principios de la
Tormenta de ideas e insiste en la importancia de tenerlos en
cuenta. La sesión comienza con una ambientación de
unos 10 minutos, tratando un tema sencillo y no comprometido. Es
una fase especialmente importante para los miembros sin
experiencia. Se determina el problema, delimitándolo,
precisándolo y clarificándolo. A
continuación se plantea el problema, recogiendo las
experiencias que se poseen o consultando documentación. Cuando es complejo, conviene
dividirlo en partes. Aquí es importante la
utilización del análisis, desmenuzando el problema en
pequeñas partes para conectar lo nuevo y lo
desconocido.

Producir ideas (es la fase de tormenta de ideas propiamente
dicha)

Se van aplicando alternativas. Se busca producir una gran
cantidad de ideas, aplicando los principios que hemos visto.
Además, es útil cuando se ha trabajado mucho,
alejarse del problema, pues es un buen momento para que se
produzcan asociaciones. Muchas de las nuevas ideas serán
ideas antigüas, mejoradas o combinadas con varias ya
conocidas.

Al final de la reunión, el director da las gracias a
los asistentes y les ruega que no abandonen el problema, ya que
al día siguiente se le pedirá una lista de ideas
que les puedan haber surgido. Se incorporan las ideas surgidas
después de la reunión.

Descubrir soluciones

Se elabora una lista definitiva de ideas, para seleccionar las
más interesantes.  La selección
se realiza desechando las ideas que no tienen valor y se estudia
si son válidas las que se consideran interesantes. Lo
mejor es establecer una lista de criterios de conveniencia para
cada idea. Se seleccionan las ideas más útiles y si
es necesario se ponderarán. Pueden realizarlo los mismos
miembros del grupo o crear otros para esta tarea; la
clasificación debe hacerse por categorías (tarea
que corresponde al director). Se presentan las ideas de forma
atractiva, haciendo uso de soportes visuales. 

Prototipos

Los prototipos permiten al desarrollador crear un modelo del
software que debe
ser construido.

Al igual que todos los enfoques al proceso de
desarrollo del
software, el
prototipado comienza con la captura de requerimientos.
Desarrolladores y clientes se
reúnen y definen los objetivos
globales del software, identifican todos los requerimientos que
son conocidos, y señalan áreas en las que
será necesaria la profundización en las
definiciones. Luego de esto, tiene lugar un "diseño
rápido". El diseño
rápido se centra en una representación de aquellos
aspectos del software que serán visibles al usuario (por
ejemplo, entradas y formatos de las salidas). El diseño
rápido lleva a la construcción de un prototipo. El prototipo
es evaluado por el cliente y el
usuario y utilizado para refinar los requerimientos del software
a ser desarrollado. Un proceso de iteración tiene lugar a
medida que el prototipo es "puesto a punto" para satisfacer las
necesidades del cliente y permitiendo al mismo tiempo una mejor
comprensión del problema por parte del desarrollador.

Existen principalmente dos tipos de prototipos:

Prototipo rápido (o concept prototipe): El prototipado
rápido es un mecanismo para lograr la validación
pre-compromiso. Se utiliza para validar requerimientos en una
etapa previa al diseño específico. En este sentido,
el prototipo puede ser visto como una aceptación
tácita de que los requerimientos no son totalmente
conocidos o entendidos antes del diseño y la
implementación. El prototipo rápido puede ser usado
como un medio para explorar nuevos requerimientos y así
ayudar a "controlar" su constante evolución.

Prototipo evolutivo: Desde una perspectiva diferente, todo el
ciclo de vida
de un producto puede ser visto como una serie incremental de
detallados prototipos acumulativos. Tradicionalmente, el ciclo de vida
está dividido en dos fases distintas: desarrollo y
mantenimiento.
La experiencia ha demostrado que esta distinción es
arbitraria y va en contra de la realidad ya que la mayor parte
del costo del
software ocurre después de que el producto se ha
entregado. El punto de vista evolutivo del ciclo de vida del
software considera a la primera entrega como un prototipo inicial
en el campo. Modificaciones y mejoras subsecuentes resultan en
nuevas entregas de prototipos más maduros. Este proceso
continúa hasta que se haya desarrollado el producto final.
La adopción
de esta óptica
elimina la distinción arbitraria entre desarrollo y
mantenimiento,
resultando en un importante cambio de
mentalidad que afecta las estrategias para
la estimación de costos, enfoques
de desarrollo y adquisición de productos.

Proceso de Análisis Jerárquico (AHP)

Esta técnica tiene por objetivo
resolver problemas cuantitativos, para facilitar el pensamiento
analítico y las métricas. Consiste en una serie de
pasos a saber:

• Encontrar los requerimientos que van a ser
  priorizados.
• Combinar los requerimientos en las filas y columnas de la
  matriz n x n
  de AHP.
• Hacer algunas comparaciones de los requerimientos en la
  matriz
• Sumar las columnas
• Normalizar la suma de las filas
• Calcular los promedios

Estos pasos pueden aplicarse fácilmente a una cantidad
pequeña de requerimientos, sin embargo, para un volumen grande,
esta técnica no es la más adecuada.

Administración de Requerimientos con Casos de Uso

¿Qué son los Casos de Uso?

Los casos de uso son una técnica para especificar el
comportamiento
de un sistema: "Un caso de uso es una secuencia de interacciones
entre un sistema y alguien o algo que usa alguno de sus servicios."

Todo sistema de software ofrece a su entorno una serie de
servicios. Un
caso de uso es una forma de expresar cómo alguien o algo
externo a un sistema lo usa. Cuando decimos "alguien o algo"
hacemos referencia a que los sistemas son usados no sólo
por personas, sino también por otros sistemas de hardware y software.

Por ejemplo, un sistema de ventas, si
pretende tener éxito, debe ofrecer un servicio para
ingresar un nuevo pedido de un cliente. Cuando un usuario accede
a este servicio,
podemos decir que está "ejecutando" el caso de uso
ingresando pedido.

Los Casos de Uso fueron introducidos por Jacobson en 1992
[Jacobson92]. Sin embargo, la idea de especificar un sistema a
partir de su interacción con el entorno es original de
McMenamin y Palmer, dos precursores del análisis
estructurado, que en 1984 definieron un concepto muy
parecido al del caso de uso: el evento. Para McMenamin y Palmer,
un evento es algo que ocurre fuera de los límites
del sistema, ante lo cual el sistema debe responder. Siguiendo
con nuestro ejemplo anterior, nuestro sistema de ventas
tendrá un evento "Cliente hace Pedido". En este caso el
sistema deberá responder al estimulo que recibe.

Sin embargo, existen algunas diferencias entre los casos de
uso y los eventos. Las
principales son:

• Los eventos se
  centran en describir qué hace el sistema cuando el
  evento ocurre, mientras que los casos de uso se centran en
  describir cómo es el diálogo entre el usuario y el
  sistema.
• Los eventos son "atómicos": se recibe una entrada,
  se la procesa, y se genera una salida, mientras que los casos
  de uso se prolongan a lo largo del tiempo mientras
  dure la interacción del usuario con el sistema. De esta
  forma, un caso de uso puede agrupar a varios eventos.
• Para los eventos, lo importante es qué datos ingresan
  al sistema o salen de él cuando ocurre el evento (estos
  datos se llaman datos esenciales), mientras que para los casos
  de uso la importancia del detalle sobre la información
  que se intercambia es secundaria. Según esta
  técnica, ya habrá tiempo más adelante en
  el desarrollo del sistema para ocuparse de este tema.

Los casos de uso combinan el concepto de
evento del análisis estructurado con otra técnica
de especificación de requerimientos bastante poco
difundida: aquella que dice que una buena forma de expresar los
requerimientos de un sistema es escribir su manual de usuario
antes de construirlo. Esta técnica, si bien ganó
pocos adeptos, se basa en un concepto muy interesante: al definir
requerimientos, es importante describir al sistema desde el punto
de vista de aquél que lo va a usar, y no desde el punto de
vista del que lo va a construir. De esta forma, es más
fácil validar que los requerimientos documentados son los
verdaderos requerimientos de los usuarios, ya que éstos
comprenderán fácilmente la forma en la que
están expresados.

Los Casos de Uso y UML

A partir de la publicación del libro de
Jacobson, gran parte de los más reconocidos especialistas
en métodos
Orientados a Objetos coincidieron en considerar a los casos de
uso como una excelente forma de especificar el comportamiento
externo de un sistema. De esta forma, la notación de los
casos de uso fue incorporada al lenguaje
estándar de modelado UML (Unified
Modeling Language) propuesto por Ivar Jacobson, James Rumbaugh y
Grady Booch, tres de los precursores de las metodologías
de Análisis y Diseño Orientado a Objetos, y avalado
por las principales empresas que
desarrollan software en el mundo. UML va en camino
de convertirse en un estándar para modelado de sistemas de
software de amplia difusión.

A pesar de ser considerada una técnica de
Análisis Orientado a Objetos, es importante destacar que
los casos de uso poco tienen que ver con entender a un sistema
como un conjunto de objetos que interactúan, que es la
premisa básica del análisis orientado a objetos
"clásico". En este sentido, el éxito de los casos
de uso no hace más que dar la razón al
análisis estructurado, que propone que la mejor forma de
empezar a entender un sistema es a partir de los servicios o
funciones que
ofrece a su entorno, independientemente de los objetos que
interactúan dentro del sistema para proveerlos.

Como era de esperar, es probable que en el futuro los
métodos de análisis y diseño que prevalezcan
hayan adoptado las principales ventajas de todos los
métodos disponibles en la actualidad (estructurados,
métodos formales, métodos orientados a objetos,
etc.).

Definiciones y Notaciones

Actores

Un actor es una agrupación uniforme de personas,
sistemas o máquinas
que interactúan con el sistema que estamos construyendo de
la misma forma. Por ejemplo, para una empresa que
recibe pedidos en forma telefónica, todos los operadores
que reciban pedidos y los ingresen en un sistema de ventas, si
pueden hacer las mismas cosas con el sistema, son considerados un
único actor: "Empleado de Ventas".

Los actores son externos al sistema que vamos a desarrollar.
Por lo tanto, al identificar actores estamos empezando a
delimitar el sistema, y a definir su alcance. Definir el alcance
del sistema debe ser el primer objetivo de
todo analista, ya que un proyecto sin alcance definido nunca
podrá alcanzar sus objetivos.

Es importante tener clara la diferencia entre usuario y actor.
Un actor es una clase de rol, mientras que un usuario es una
persona que, cuando usa el sistema, asume un rol. De esta forma,
un usuario puede acceder al sistema como distintos actores. La
forma más simple de entender esto es pensar en perfiles de
usuario de un sistema
operativo. Una misma persona puede acceder al sistema con
distintos perfiles, que le permiten hacer cosas distintas. Los
perfiles son en este caso equivalentes a los actores.

Otro sistema que interactúa con el que estamos
construyendo también es un actor. Por ejemplo, si nuestro
sistema deberá generar asientos contables para ser
procesados por el sistema de contabilidad,
este último sistema será un actor, que usa los
servicios de nuestro sistema.

También puede ocurrir que el actor sea una
máquina, en el caso en que el software controle sus
movimientos, o sea operado por una máquina. Por ejemplo,
si estamos construyendo un sistema para mover el brazo de un
robot, el hardware del robot
será un actor, asumiendo que dentro de nuestro sistema
están las rutinas de bajo nivel que controlan al
hardware.

Los actores se representan con dibujos
simplificados de personas, llamados en inglés
"stick man" (hombres de palo).

Si bien en UML los actores siempre se representan con
"hombres de palo", a veces resulta útil representar a
otros sistemas con alguna representación más
clara.

Las flechas, que existían en la propuesta original
de Jacobson, pero que desaparecieron del modelo
semántico de UML, pueden usarse para indicar el flujo de
información entre el sistema y el actor. Si la flecha
apunta desde el actor hacia el sistema, esto indica que el actor
está ingresando información en el sistema. Si la
flecha apunta desde el sistema hacia el actor, el sistema
está generando información para el actor.

Identificar a los actores es el primer paso para usar la
técnica de casos de uso. Por ejemplo, en el sistema de
pedidos nombrado anteriormente, sin conocer prácticamente
ningún detalle sobre cómo funcionará,
podemos decir que:

• El grupo de usuarios que ingrese pedidos al sistema
  será un actor.
• El grupo de usuarios que haga otras operaciones
  con los pedidos, como por ejemplo autorizarlos, cancelarlos y
  modificar sus plazos de entrega, será un
  actor.
• Todo grupo de usuarios que reciba ciertos informes
  del sistema, como por ejemplo estadísticas de ventas, será un
  actor.

Es común que los distintos actores coincidan con
distintas áreas de la empresa en la
que se implementará el sistema, o con jerarquías
dentro de la
organización (empleado, supervisor y gerente son
distintos actores, si realizan tareas distintas).

Todos los actores participan de los casos de uso. Ahora
bien, es lógico que existan intersecciones entre lo que
hacen los distintos actores. Por ejemplo, un supervisor puede
autorizar pedidos, pero también puede ingresarlos. Veremos
más adelante cómo, definiendo actores abstractos,
podemos especificar este comportamiento común para evitar
redundancia.

Casos de Uso

Como mencionamos anteriormente, un caso de uso es una
secuencia de interacciones entre un sistema y alguien o algo que
usa alguno de sus servicios. Un caso de uso es iniciado por un
actor. A partir de ese momento, ese actor, junto con otros
actores, intercambian datos o control con el
sistema, participando de ese caso de uso.

El nombre de un caso de uso se expresa con un verbo en
gerundio, seguido generalmente por el principal objeto o entidad
del sistema que es afectado por el caso. Gráficamente, los
casos de uso se representan con un óvalo, con el nombre
del caso en su interior.

Es importante notar que el nombre del caso siempre
está expresado desde el punto de vista del actor y no
desde el punto de vista del sistema. Por eso el segundo caso de
uso se llama "Recibiendo información de pedidos" y no
"Generando información de pedidos".

Los casos de uso tienen las siguientes características:

• Están expresados desde el punto de vista del
  actor.
• Se documentan con texto
  informal.
• Describen tanto lo que hace el actor como lo que
  hace el sistema cuando interactúa con él,
  aunque el énfasis está puesto en la
  interacción.
• Son iniciados por un único
  actor.
• Están acotados al uso de una determinada
  funcionalidad del sistema, claramente
  diferenciada.

El último punto es tal vez el más
difícil de definir. Uno podría, después de
todo, decir que todo sistema tiene un único caso de uso
denominado "Usando el Sistema". Sin embargo, la
especificación resultante sería de poco utilidad para
entenderlo; sería como implementar un gran sistema
escribiendo un único programa.

La pregunta importante es: ¿Qué es una
"funcionalidad claramente diferenciada"? Por ejemplo,
¿ingresar pedidos es un caso de uso y autorizarlos es
otro? ¿Cancelar los pedidos, es otro caso de uso, o es
parte del caso de uso referido al ingreso de pedidos?

Si bien se pueden encontrar argumentos válidos
para cualquiera de las dos alternativas, en principio la
respuesta a todas estas preguntas es que todos son casos de uso
distintos. Lamentablemente, si en la programación los criterios para dividir la
funcionalidad en programas suelen
ser difusos, los criterios para dividir la funcionalidad de un
sistema en casos de uso son aún más difusos, y por
esto se hace importante usar el sentido común en estas
decisiones.

En principio, podríamos decir que la regla
general es: una función del sistema es un caso de uso si
se debe indicar explícitamente al sistema que uno quiere
acceder a esa función. Por ejemplo, si uno quiere dar de
alta un pedido, accederá a la funcionalidad de "alta de
pedidos del sistema". Sin embargo, si uno quiere dar de alta un
campo del pedido, no debe indicar al sistema que quiere acceder a
esa función. Dar de alta un campo de un pedido es una
función que forma parte de un caso de uso mayor: "dar de
alta un pedido".

Cuando pensamos en el grado de detalle de la
división de los casos de uso también resulta
útil imaginar que uno está escribiendo el manual del
usuario del sistema. A nadie se le ocurriría escribir un
manual de usuario con un solo capítulo en el que se
describe toda su funcionalidad. De la misma forma, no se debe
escribir una especificación con un solo caso de
uso.

Extensiones (Extends)

Muchas veces, la funcionalidad de un caso de uso incluye
un conjunto de pasos que ocurren sólo en algunas
oportunidades. Supongamos que estamos especificando un sistema en
el cual los clientes pueden
ingresar pedidos interactivamente, y que dentro de la
funcionalidad del ingreso de pedidos el usuario puede solicitar
al sistema que le haga una presentación sobre los nuevos
productos disponibles, sus características y sus precios. En
este caso, tengo una excepción dentro del caso de uso
"Ingresando Pedido". La excepción consiste en interrumpir
el caso de uso y pasar a ejecutar el caso de uso "Revisando
Presentación de Nuevos Productos". En este caso decimos
que el caso de uso "Revisando Presentación de Nuevos
Productos", extiende el caso de uso "Ingresando Pedido" y se
representa por una línea de trazos desde el caso que
‘extiende a’ al caso que es
‘extendido’.

Las extensiones tienen las siguientes
características:

• Representan una parte de la funcionalidad del caso
  que no siempre ocurre.
• Son un caso de uso en sí mismas.
• No necesariamente provienen de un error o
  excepción.

Usos (Uses)

Es común que la misma funcionalidad del sistema
sea accedida a partir de varios casos de uso. Por ejemplo, la
funcionalidad de buscar un producto puede ser accedida desde el
ingreso de pedidos, desde las consultas de productos, o desde los
reportes de ventas por producto. ¿Cómo hago para no
repetir el texto de esta
funcionalidad en todos los casos de uso que la acceden? La
respuesta es simple: sacando esta funcionalidad a un nuevo caso
de uso, que es usado por los casos de los cuales fue sacada. Este
tipo de relaciones se llama relaciones de uso y se representa por
una línea punteada desde el caso que ‘usa a’
al caso que es ‘usado’.

Decimos, por ejemplo, que el caso de uso "Obteniendo
reporte de ventas por producto", usa al caso de uso "Buscando
producto".

Este concepto no es novedoso, es simplemente el concepto
de la subrutina o subprograma usado en un nivel más alto
de abstracción.

Las características de las relaciones de uso
son:

• Aparecen como funcionalidad común, luego de
  haber especificado varios casos de uso.
• Los casos usados son casos de uso en sí
  mismos.
• El caso es usado siempre que el caso que lo usa es
  ejecutado. Esto marca la
  diferencia con las extensiones, que son
  opcionales.

Abstracción

Al identificar relaciones de uso y extensión,
puede ser que extraigamos casos de uso que son accedidos por
varios actores. Por ejemplo, el caso de uso "buscando datos de
producto" es accedido por muchos actores (el empleado de ventas
que ingresa un pedido, el gerente que
quiere obtener estadísticas por producto, el supervisor
que quiere consultar la información de algún
producto, etc.). Ahora bien, como el caso de uso nunca se ejecuta
fuera del contexto de otro caso de uso, decimos que es un caso de
uso abstracto. Lo llamamos abstracto porque no es implementable
por sí mismo: sólo tiene sentido como parte de
otros casos.

De la misma forma, el actor que participa de este caso
de uso, que reúne características comunes a todos
los actores de los casos de uso que lo usan, es un actor
abstracto. En nuestro ejemplo, podemos decir que tenemos un actor
abstracto "Buscador de Datos de Producto". Los actores
abstractos, entonces, son necesarios para no dejar sin actores a
los casos de uso abstractos.

Herencia

La duda ahora es cómo relacionar este actor
abstracto con los actores concretos: los que sí existen en
la realidad y ejecutan casos de uso concretos, como "ingresando
pedido" y "obteniendo estadísticas de ventas".

Para esto podemos usar el concepto de herencia, uno de
los conceptos básicos de la orientación a objetos.
Como todos los actores concretos también ejecutan el caso
"buscando datos de producto", a través de la
relación de uso, podemos decir que los actores concretos
heredan al actor abstracto.

La relación de herencia no
necesariamente implica la existencia de un caso abstracto. Puede
ocurrir que un actor ejecute todos los casos que ejecuta otro
actor, y algunos más. En nuestro sistema, el supervisor de
ventas puede hacer todo lo que hace el empleado de ventas, pero
además puede autorizar pedidos. En este caso, podemos
decir que el Supervisor de Ventas hereda al Empleado de Ventas,
aunque el Empleado de Ventas no sea un actor abstracto. De esta
forma, toda la funcionalidad que está habilitada para el
Empleado de Ventas también lo está para el
Supervisor.

El Proceso de Ingeniería de Requerimientos con Casos de
Uso
A continuación, se describen los pasos a seguir para
aplicar la técnica con casos de uso a la IR.
Identificar los Actores
Si la primera pregunta que un analista debe hacer a sus usuarios
es ¿Para qué es este sistema?, la segunda es
claramente ¿Para quiénes es este sistema? Como
mencionamos al hablar sobre los actores, identificar a todos
ellos es crítico para un buen análisis de
requerimientos. Por lo tanto, antes de avanzar con los casos de
uso, debo tratar de identificar todos los tipos de usuario
diferentes que tiene el sistema. Si el sistema será
implementado en una empresa, debo
preguntar cuáles de las áreas afectadas
usarán o actualizarán su
información.

A pesar de hacer una identificación inicial de
los actores, también debo repetirla a medida que empiezo a
describir los casos de uso, ya que al conocer más detalles
del sistema, pueden aparecer nuevos tipos de usuarios.

Identificar los Principales Casos de uso de cada
Actor

El siguiente paso es enunciar los nombres de los
principales casos de uso de cada uno de los actores que se
identificaron en el paso anterior. No es necesario especificar
cuáles son las acciones
dentro del caso de uso. Tampoco debo preocuparme si no aparecen
muchos casos, ya que existen técnicas para encontrar
nuevos casos de uso a partir de los existentes.

Identificar Nuevos Casos a Partir de los
Existentes

Uno de los principales errores que se pueden cometer al
identificar requerimientos es algo que parece obvio, pero que
muchas veces ocurre: ¡olvidarse de algún
requerimiento! Como los requerimientos están en la cabeza
de los usuarios, el éxito de esta tarea depende de la
habilidad del analista. Para ayudarnos a identificar nuevos casos
de uso a partir de los casos existentes, podemos aplicar las
mismas técnicas utilizadas para identificar eventos
según el análisis estructurado. Algunas de las
preguntas que debemos hacernos son:

• ¿Cuáles son las tareas de un
  actor?
• ¿Necesita el actor estar informado de ciertas
  ocurrencias del sistema?
• ¿Necesita el actor informar al sistema de
  cambios externos súbitos?
• ¿Proporciona el sistema el comportamiento
  correcto al negocio?
• ¿Pueden ser todos los requerimientos
  funcionales, desarrollados por los casos de uso?
• ¿Qué casos de uso soportarán y
  mantendrán al sistema?
• ¿Qué información debe ser
  modificada o creada?

Documentación de Casos de Uso

Una vez que identificamos todos los casos de uso,
empezamos a documentar sus pasos; este documento se crea para
cada caso de uso, detallando lo que el sistema debe proporcionar
al actor cuando el caso de uso es ejecutado. Esta tarea no es
estrictamente secuencial de la anterior: es posible que, mientras
empezamos a documentar los casos, sigamos buscando otros
nuevos.

Un contenido típico de un documento de caso de
uso sería:

• Describir cómo comienza el caso de uso y
  cómo termina.
• Realizar un flujo normal de eventos.
• Realizar un flujo alterno de eventos.
• Detallar las excepciones al flujo de
  eventos.

Definir Prioridades

Una vez documentados los casos de uso, es conveniente
definir las prioridades de los distintos requerimientos,
expresados como casos de uso. Para los escenarios claves y los
casos de uso que serán analizados en su iteración,
se debe:

• Representar la funcionalidad central de cada caso de
  uso.
• Cubrir varios aspectos de arquitectura.
• Poner bajo estrés
  un punto delicado de la arquitectura.

Gráficos a Utilizar

Dependiendo del tamaño del sistema, es probable
que un único gráfico con todos los casos de uso nos
quede chico. No olvidemos que los modelos
gráficos son para aclarar el texto, y no
para confundir. Si el gráfico de casos de uso es una
maraña indescifrable, no está cumpliendo su
objetivo. Por lo tanto, podemos usar las siguientes reglas para
incluir gráficos de casos de uso dentro de la
SRS.

• Un gráfico de casos de uso no debe mostrar
  más de 15 casos
• Si es necesario particionar el gráfico, debe
  hacerse por actor. La primera partición debe separar
  los casos centrales de los casos auxiliares, ya que
  probablemente les interesen a personas distintas.
• Si las relaciones de uso y las extensiones entran
  en el diagrama
  principal, sin dejar de cumplir con la regla 1, debo dejarlas
  ahí. Lo mismo se aplica a los actores
  abstractos.
• Si las relaciones de uso no entran en el diagrama
  principal, debo mostrarlas en gráficos teniendo en
  cuenta que siempre debo mostrar todos los casos de uso que
  usan a otro en un mismo diagrama.
• Si tengo un caso de uso que es usado por gran parte
  de los otros casos, como por ejemplo el caso de uso
  "Identificándose ante el sistema", debo evitar
  mostrarlo en el gráfico principal, ya que las flechas
  serán imposibles de organizar. Es probable que no haga
  falta mostrar esta relación de uso en un
  gráfico.

Herramientas automatizadas para la Administración de Requerimientos

Hoy en día, la Ingeniería de
Software cuenta con una serie de herramientas
automatizadas destinadas a diferentes propósitos. Dentro
de las herramientas
CASE que sirven de apoyo a los procesos de
Ingeniería
de Software, están las especializadas en la
administración de requisitos. Estas herramientas se
concentran en capturar requerimientos, administrarlos y producir
una especificación de requisitos.

Las ventajas que nos proporcionan la herramientas
automatizadas para IR son:

• Permiten un mayor control de
  proyectos
  complejos.
• Permiten reducir costos y
  retrasos en la liberación de un proyecto.
• Permiten una mayor comunicación en equipos de
  trabajo.
• Ayudan a determinar la complejidad del proyecto y
  esfuerzos necesarios.

En este capítulo veremos dos de las herramientas
más utilizadas para este propósito: RequisitePro y
DOORS.

RequisitePro
RequisitePro(R) es la
herramienta que ofrece Rational Software para tener un mayor
control sobre los requerimientos planteados por el usuario y
todos aquellos requerimientos técnicos o nuevos
requerimientos de usuario que surjan durante el ciclo de vida del
proyecto.

Con RequisitePro los requerimientos se encuentran
documentados bajo un esquema organizado de documentos;
éstos esquemas, cumplen completamente con los
estándares requeridos por IEEE, ISO, SEI, CMM
y por el Rational Unified Process.

RequisitePro se integra con aplicaciones para la
administración de cambios, herramientas de
modelado de sistemas y con herramientas de pruebas. Esta
integración asegura que los
diseñadores conocen los requerimientos del usuario, del
sistema y del software en el momento de su desarrollo.
RequisitePro permite el desarrollo en equipo, vía el
check-in y check-out de los documentos
involucrados en el proyecto. Con esta integración, se pueden conservar juntos
todos los requerimientos y ser manipulados por todos y cada uno
de los miembros del equipo.

Todos los requerimientos tienen atributos y estos son la
principal fuente de información para ayudarle a planear,
comunicar y rastrear las actividades del proyecto a través
del ciclo de vida. Cada proyecto tiene necesidades únicas
y se deberán seleccionar los atributos que sean
críticos para asegurar su éxito: prioridad de
desarrollo, status, autor, responsable, relaciones, fecha de
registro,
fecha última modificación, versión,
etc.

RequisitePro permite la asignación de prioridades
a los requerimientos en base a:

• Beneficios al cliente: Todos los requerimientos no
  son desarrollados de igual forma. Se les da prioridad en base a
  la importancia relativa del usuario final basado en un
  análisis previo de los analistas y desarrolladores del
  equipo.
• Esfuerzo: Claramente, algunos requerimientos o
  cambios a éstos demandan más tiempo y recursos que
  otros. Estimar el número de semanas-personas o
  líneas de código requeridas en base a
  requerimientos, es la mejor forma de determinar que y que no
  puede ser desarrollado en el tiempo estipulado.

Una característica importante es que la curva de
aprendizaje de
RequisitePro es pequeña, este aprendizaje puede
ser basado en el uso de los tutoriales,
los cuales guían por los puntos principales en el uso de
la herramienta.

Beneficios de RequisitePro

• Permite el trabajo en
  equipo por medio de un repositorio compartido de
  información.
• Permite la clasificación de requerimientos, en
  base a las necesidades de cada empresa:
   usuario, técnicos, comunicación, pruebas.
• Define atributos para todos los tipos de
  requerimientos especificados.
• Ayuda a manipular el alcance del proyecto mediante la
  asignación de prioridad de desarrollo a cada uno de los
  requerimientos planteados.
• Características avanzadas de rastreo, por
  medio de matrices,
  que permiten visualizar las dependencias entre requerimientos
  dentro de un proyecto o en diferentes proyectos.
• Marcas que automáticamente indican
  cuándo un requerimiento es impactado por cambios a otro
  requerimiento o a atributos asociados.
• Administración de cambios mediante el rastreo
  y la visualización histórica de los cambios
  efectuados al requerimiento, cuándo y quién los
  realizó.
• Manejo de plantillas creadas por el usuario, o
  creadas por otras empresas.
• Recolección de requerimientos mediante su
  importación por medio de Wizards para
  obtenerlos automáticamente de fuentes
  externas, incluyendo archivos o
  bases de
  datos.
• Interactúa con los demás productos
  Rational para el ciclo de vida, así como con
  herramientas de Microsoft
  Office.
• Ayuda a determinar en forma automatizada
  cuántos requerimientos tiene el proyecto.
• Ayuda a determinar responsables y actores en cada uno
  de los requerimientos.
• RequisitePro, le permite organizar sus
  requerimientos, establecer y mantener relaciones padre/hijo
  entre ellos.

Doors
DOORS(R) es la herramienta de
administración de requisitos creada por Quality Systems
and Software. Esta herramienta permite capturar, relacionar,
analizar y administrar un rango de información para
asegurar el cumplimiento del proyecto en materia de
requerimientos.
DOORS' permite el acceso de un gran número de
usuarios concurrentes en la red, manteniendo en
línea un gran número de requerimientos así
como su información asociada.
DOORS ayuda al usuario a procesar las solicitudes de cambios de
requerimientos en línea. Permite realizar cualquier
modificación vía remota cuando la base de datos
está off-line, incorporando sus actualizaciones a la
base de datos
maestra. Esto hace más fácil la
comunicación del equipo con otras organizaciones,
subcontratistas y proveedores.

Esta herramienta proporciona rastreabilidad multi-nivel
para aquellas relaciones entre requerimientos que poseen gran
tamaño. DOORS cuenta con un wizard que le permite generar
enlaces a reportes de muchos niveles, para desplegarlos en la
misma vista.

Beneficios de DOORS

• Análisis y comparación de
  requerimientos.
• Clasificación de requerimientos.
• Interpretación manual de cada
  requerimiento.
• Identificación de Inconsistencias.
• Operación vía batch.
• Permite compartir requerimientos entre
  proyectos.
• Permite crear relaciones entre requerimientos
  mediante la táctica drag-and-drop
• Envía una notificación vía email
  cuando los cambios son revisados.
• Permite visualizar los cambios pendientes de otros
  usuarios para anticipar el impacto que
  ocasionará.
• Despliega estadísticas y métricas a
  través de gráficas.
• Los documentos están escritos en lenguaje
  claro, lo que proporciona una comprensión inmediata de
  cada requerimiento.
• Permite importar sus documentos a formatos de
  herramientas de Microsoft
  Office, RTF,
  HTML, texto,
  entre otros.
• Las plantillas presentan la información de
  manera estandarizada.

4. Análisis comparativo
de las técnicas de ingeniería de
requerimientos

En este capítulo se presentan las principales
ventajas y desventajas de cada una de las técnicas
utilizadas en las etapas de la Ingeniería de
Requerimientos.

En base a las ventajas y
desventajas mostradas anteriormente, se hace una
comparación entre algunas de las
técnicas.

Entrevistas vs. Casos de Uso: Un alto porcentaje
de la información recolectada durante una entrevista,
puede ser usada para construir casos de uso. Mediante esto, el
equipo de desarrollo puede entender mejor el ambiente de trabajo
de los involucrados. Cuando el analista sienta que tiene
dificultades para entender una tarea, pueden recurrir al uso de
un cuestionario y mostrar los detalles recavados en un caso de
uso. De hecho, durante las entrevistas
cualquier usuario puede utilizar diagramas de
casos de uso para explicar su entorno de
trabajo.

Entrevistas vs. Lluvia de Ideas: Muchas de las
ideas planteadas en el grupo, provienen información
recopilada en entrevistas o cuestionarios previos. Realmente la
lluvia de ideas trata de encontrar las dificultades que existen
para la comprensión de términos y conceptos por
parte de los participantes; de esta forma se llega a un
consenso.

Casos de Uso vs. Lluvia de Ideas: La lista de
ideas proveniente del brainstorm puede ser representada
gráficamente mediante casos de uso.

El siguiente cuadro muestra las
técnicas que pueden ser utilizadas en las diferentes
actividades de la IR.

5.
Conclusiones Y Recomendaciones

A pesar de la importancia que tiene la
Ingeniería de Requerimientos, ha costado mucho que se le
preste la atención adecuada a esta actividad. Aún
quedan muchos desafíos que deben ser mejorados, tales como
la integración de requerimientos funcionales y no
funcionales, la evaluación
de especificaciones alternativas, la formalización de la
SRS, entre otras.

Cada actividad y técnica de la IR utilizada
individualmente, dará diferentes soluciones para
diferentes proyectos, incluyendo aquellos casos en los que el
dominio y el
área del problema son el mismo. Por esta razón,
considero que no existe un modelo de proceso ideal para la IR;
encontrar el método o
la técnica perfecta es una ilusión, pues cada
método y técnica ofrece diferentes soluciones ante
un problema.

En esta investigación se presentaron una serie de
actividades y técnicas, que no pertenecen a un modelo de
proceso en sí, sino, que son una alternativa al material
publicado por diferentes autores y que, desde mi punto de vista,
son las más importantes.

Debemos recordar que la Ingeniería de
Requerimientos es una actividad que involucra a clientes,
usuarios, equipo de desarrollo, administradores de proyectos,
etc.; por lo tanto, el proceso de IR no depende solamente de la
forma en cómo se percibe el problema, sino también,
del nivel de experiencia que tengan los
involucrados.

Tomando en cuenta la magnitud de comunicación
y el trabajo en
equipo que debe existir en la IR, considero necesario enfatizar
más en cerrar las brechas que todavía existen,
incluyendo los siguientes elementos:

• Factores sociales: involucrar al grupo para
  compartir sus experiencias.
• Factores de problemas específicos: el
  dominio de la estructura y
  estándares disponibles.
• Factores organizacionales: tiempo y costo
  presupuestados.
• Factores de diseño: por ejemplo, interfases
  de usuario

Es importante tomarse el tiempo necesario para
conocer a nuestros clientes y usuarios, así como su
ambiente de trabajo. Esto, también ayuda a establecer una
buena relación de trabajo y comunicación entre el
equipo de desarrollo y los clientes. Es realmente necesario que
los clientes y usuarios participen en la definición de sus
requerimientos, pues ellos son los que deciden nuestro destino en
el proyecto, deciden si les gustamos o no y además
financian el proyecto.

En cuanto a la investigación realizada de la
técnica de Casos de Uso para la Ingeniería de
Requerimientos, puede decirse que los casos de uso son
independientes del método de diseño que se utilice,
y por lo tanto, del método de programación. Luego de documentar los
requerimientos de un sistema con casos de uso, se puede
diseñar un sistema "estructurado" (manteniendo una
separación entre datos y funciones), o un
sistema Orientado a Objetos, sin que la técnica sea de
mayor o menor utilidad en
alguno de los dos casos. Esto da más flexibilidad al
método, y probablemente contribuya a su
éxito.

Otro punto a considerar, es la inclusión del
término "Administración de Requerimientos" en la
década de los 90. Con esta nueva visión, se busca
encontrar una descripción más apropiada de las
actividades involucradas, a la vez de enfatizar la importancia de
mantener una buena relación entre los afectados y el
equipo del proyecto.

Entregar software de calidad, a tiempo y dentro del
presupuesto,
hará que nuestros clientes confíen y
asegurará el crecimiento y madurez de la relación
de negocio.

6. Referencias
Bibliográficas

Libros
Senn, James A. "Análisis y
Diseño de Sistemas de Información". Segunda
Edición. McGraw Hill. 1992.
Fowler, Martín. "UML Gota a Gota". Primera edición.
Addison Wesley Longman. 1999.
Publicaciones de diferentes Universidades encontradas en el
Web
Brackett, Jhon W. "Software Requirements". Software Engineering
Institute Education Program – Carnegie Mellon
University.
1990.
Saiedian, H.; Dale, R. "Requirements Engineering: Making the
connection between the software developer and customer".
Department of Computer Science – University of Nebraska.
1999.
Oberg, Roger; Probasco Leslee; Ericsson, Maria. "Applying
Requirements Management with Use Cases". Rational Software
Corporation. 1998.
Hofmann, Hubert. "Requirements Engineering". Institute for
Informatics – University of Zurich. 1993.
Object Management Group. "OMG Unified Modeling Language
Specification". 1999.
Malan, Ruth. "Functional Requirements and Use Cases".
Hewlette-Packard Company. 1999.
International Council of Systems Engineering. "INSIGTH –
Requirements Sharing the Vision". Volumen 4. INCOSE. 2000.
Direcciones electrónicas sobre este tema
IEEE Task Force on Requirements Engineering. http://www.shu.ac.uk/tfre/web.links.html
Software Engineering Resources by Roger S. Pressman &
Associates Inc. http://www.rspa.com/spi/index.html
Lista de publicaciones de un grupo de Ingeniería de
Software. http://www.soi.city.ac.uk/~gespan/sw_group_pub.html
Publicaciones de Elsevier Science.
http://www.elsevier.nl/

Autor:

Lizka Johany Herrera J.